把形容詞變成規則,把規則變成例子,把例子變成可執行的測試。
UAT 要像『路考』而非『展演』:用真的路、真的車、真的時間。
貝老闆:「小可啊,客戶說後台要做『簡單好用』的報表。我們上週不是過 UAT 了嗎?怎又說不是他要的?」
小可(翻白眼,右手摺扇啪): 「老闆,UAT 當天客戶只點了三下。他今天真的上線使用,才發現要匯出多工作表、手機互相切換、10 sec 下載完畢、還要套公司自定格式……哪個叫『簡單』?」
工程師 King(皺眉): 「他們沒講規則。我們把『簡單』當『步驟少』做;他們把『簡單』當『一鍵搞定所有跨表格式』做。宇宙不同頻。」
AI 實習生(單眼怪抖抖的): 「要不要我幫忙把『簡單』拆成 Given/When/Then ?」
貝老闆:「好威咧?打給他!」
(您得電話沒有回應.....)
小可:「好威烙跑了,他上次不是說可以去找三叔公!? 他才是大師啦!!」
三叔公(電話另一端):「各位,先別吵。你們現在可以先開一場 Example Mapping,把形容詞變成規則與例子。下一版 UAT 用 Gherkin 寫 scenario,還有在 DoR 寫清楚資料、裝置、權限;DoD 勾到『真實資料驗收』才算過關,但是啊....你們還是先讀一下我的文章,還有來上公開班,有了概念才好跟 AI 協作」
Feature: 後台報表匯出
Rule: 多工作表匯出須符合公司格式
Example: 主管一鍵匯出含多工作表
Given 使用者角色為「主管」且已登入
And 有三個部門的月報已產生(銷售、客服、倉儲)
When 於手機裝置點擊「一鍵匯出」
Then 下載的檔案包含三個工作表,以 Excel 格式
And 各工作表欄位順序與公司格式一致
And 於 10 秒內完成下載
用途:把『簡單好用』具象化為可驗證的步驟與門檻(誰、在哪裡、做什麼、要多久)。
1)Example Mapping:把故事講清楚
四色便利貼:黃色=故事、藍色=規則、綠色=例子、紅色=問題。開會 25 分鐘內先貼規則:如『一鍵匯出需 ≤10 秒』『主管可見跨部門』『手機與桌機皆可使用』。再為每個規則補 2~3 個例子,最後整理未決問題。請避開形容詞,用可量化的動詞與門檻。AI 可先根據需求初稿自動產出規則草案與反例,會中快速修正即可。
2)Gherkin 驗收標準:讓每句話都能被驗證,重點是大家要有共識
把需求寫成 Given/When/Then;加入角色、資料狀態、裝置與時間上限,才能避免爭議。讓 AI 針對每個規則生成至少一個 happy path 與一個 edge case,例如『網速慢於 5Mbps』『資料缺欄位』;會後直接丟到 E2E 測試框架(如 Playwright)生成腳本骨架。
3)UAT 計畫版:環境、資料、裝置一次講明
UAT 不是 Demo。計畫書要列:測試帳號與權限矩陣、需準備的真實或脫敏資料、網路情境(4G/Wi‑Fi)、瀏覽器與手機清單、關鍵任務 KPI(如 10 秒內匯出)。AI 可自動比對『產品分析的 Top 任務』與『UAT 測項』,找出缺口。
4)DoR/DoD:兩道門,防形容詞誤會
DoR(Ready)要求:規則列表、Gherkin 原型、資料樣本、裝置清單、風險與未決問題;DoD(Done)要求:自動化測試綠燈、用真實資料跑過 UAT 清單、性能門檻達標、文件更新。AI 可在 PR 時檢查這些門檻,沒過就退件。
你們團隊最近一次被客戶說「不是我要的」的原因是什麼?是形容詞過多、還是情境沒列?留言貼出你的一條『規則→例子』轉換句,讓我們幫你補齊 Gherkin。
請你扮演產品教練,根據以下需求敘述,輸出一份 Example Mapping(故事、規則、例子、問題)與 3 條 Gherkin 驗收案例,並為每條案例產生 1 個 happy path 與 1 個 edge case;同時輸出 UAT 計畫的裝置清單與資料樣本建議。需求:『後台報表要簡單好用,手機也能一鍵匯出多工作表,符合公司格式,速度要快。』